А вот скриншот из этого чуда.
P.S. Я, кстати, не подводил итоги года в отличие от моих коллег, а тем временем в канал пришло 2200+ человек за последний год. Всем спасибо! Не переставайте выполнять цели, поставленные в начале года, и не забывайте вступать в наш чат DevSecOps Chat и сторонние проекты - CloudSec Wine и AppSec and DevSecops Jobs!
#talks
P.S. Я, кстати, не подводил итоги года в отличие от моих коллег, а тем временем в канал пришло 2200+ человек за последний год. Всем спасибо! Не переставайте выполнять цели, поставленные в начале года, и не забывайте вступать в наш чат DevSecOps Chat и сторонние проекты - CloudSec Wine и AppSec and DevSecops Jobs!
#talks
Building Trust in the Software Supply Chain
В канале мы очень много говорили про различные варианты атак на цепочку поставок через CI/CD и варианты ее защиты. Предлагаю посмотреть красивую страницу "Building Trust in the Software Supply Chain" по безопасности цепочки поставок от Google, которая в свою очередь предлагает обеспечить защиту пайплайнов через подход создания свидетельствующих об искажении логов (Tamper-evident logs) и их открытого решения Trillian. В основе лежит концепция Verifiable Data Structures, гарантирующая то, что логи, получившиеся в процессе скачивания сторонних библиотек, сборки и проверки сканерами безопасности, не пострадали. Эти же логи можно проверять на целостность перед тем как задеплоить соответствующий артефакт на целевое устройство.
Помимо защиты цепочки поставок подход предлагается использовать при скачивании обновлений на конечных устройствах или при работе с финансовыми транзакциями. Кстати, фреймворк SLSA от того же Google получил отдельный веб-ресурс для изучения. В нем важность сбора логов и информации о том, что собирается, когда и кем отмечена также в отдельном направлении Provenance.
#ops
В канале мы очень много говорили про различные варианты атак на цепочку поставок через CI/CD и варианты ее защиты. Предлагаю посмотреть красивую страницу "Building Trust in the Software Supply Chain" по безопасности цепочки поставок от Google, которая в свою очередь предлагает обеспечить защиту пайплайнов через подход создания свидетельствующих об искажении логов (Tamper-evident logs) и их открытого решения Trillian. В основе лежит концепция Verifiable Data Structures, гарантирующая то, что логи, получившиеся в процессе скачивания сторонних библиотек, сборки и проверки сканерами безопасности, не пострадали. Эти же логи можно проверять на целостность перед тем как задеплоить соответствующий артефакт на целевое устройство.
Помимо защиты цепочки поставок подход предлагается использовать при скачивании обновлений на конечных устройствах или при работе с финансовыми транзакциями. Кстати, фреймворк SLSA от того же Google получил отдельный веб-ресурс для изучения. В нем важность сбора логов и информации о том, что собирается, когда и кем отмечена также в отдельном направлении Provenance.
#ops
Binary Transparency
Binary Transparency - Building Trust in the Software Supply Chain.
10 real-world stories of how we’ve compromised CI/CD pipelines
Обожаю NCC Group за их статьи и "10 real-world stories of how we’ve compromised CI/CD pipelines" не исключение. Разбираем варианты атак, где встречающийся CI/CD на пути злоумышленника становится ключевым звеном для развития вариантов компрометации: 3 примера для Jenkins (в т.ч. дамп кредов, про который я писал ранее) и 5 примеров для Gitlab (в т.ч. атаки с использованием неизолированных привилегированных раннеров). Еще 2 примера повествуют об удивительных находках ресерчеров NCC Group в контексте повышения привилегий в AWS аккаунте при наличии доступа к "ноутбуку разработчика" или посредством эксплуатации особенностей плагина Kube2IAM.
#ops
Обожаю NCC Group за их статьи и "10 real-world stories of how we’ve compromised CI/CD pipelines" не исключение. Разбираем варианты атак, где встречающийся CI/CD на пути злоумышленника становится ключевым звеном для развития вариантов компрометации: 3 примера для Jenkins (в т.ч. дамп кредов, про который я писал ранее) и 5 примеров для Gitlab (в т.ч. атаки с использованием неизолированных привилегированных раннеров). Еще 2 примера повествуют об удивительных находках ресерчеров NCC Group в контексте повышения привилегий в AWS аккаунте при наличии доступа к "ноутбуку разработчика" или посредством эксплуатации особенностей плагина Kube2IAM.
#ops
Exploiting Url Parsers: The Good, Bad, And Inconsistent
Команда Claroty совместно с Snyk опубликовала ресерч, посвященный уязвимостям в URL-парсерсах (названных URL Confussion), ведущих к SSRF, XSS, Open Redirect, обходам фильтраций и DoS. Всего было проанализирвоано 16 популярных библиотек и утилит на предмет их подверженности 5 категориям атак типа Confussion. В конце приведены также рекомендации, как использовать парсеры, чтобы минимизровать появление уязвимостей в своем вебе.
#dev #attack
Команда Claroty совместно с Snyk опубликовала ресерч, посвященный уязвимостям в URL-парсерсах (названных URL Confussion), ведущих к SSRF, XSS, Open Redirect, обходам фильтраций и DoS. Всего было проанализирвоано 16 популярных библиотек и утилит на предмет их подверженности 5 категориям атак типа Confussion. В конце приведены также рекомендации, как использовать парсеры, чтобы минимизровать появление уязвимостей в своем вебе.
#dev #attack
What does your code use, and is it vulnerable? It depends!
Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же
На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то
Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.
В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).
Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.
#sca #dev
Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же
package.json может быть указано, что пакет lodash имеет версию "*")На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то
build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.
В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).
Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.
#sca #dev
OWASP WrongSecrets
12 тасков на компрометацию секретов. Здесь есть hardcoded passwords, использование секрета в ENV, ConfigMap, AWS Secrets Manager, Vault и инжект во время сборки. Для работы с платформой, соответственно, может понадобится k8s, облако (aws, gzp, azure в experimental), minikube, vault.
#dev #secret
12 тасков на компрометацию секретов. Здесь есть hardcoded passwords, использование секрета в ENV, ConfigMap, AWS Secrets Manager, Vault и инжект во время сборки. Для работы с платформой, соответственно, может понадобится k8s, облако (aws, gzp, azure в experimental), minikube, vault.
#dev #secret
New Argo CD Bug Could Let Hackers Steal Secret Info from Kubernetes Apps
Для тех, кто еще не видел, у ArgoCD вышла CVE-2022-24348 (CVSS score: 7.7), позволяющая дампить секреты из кластера благодаря кастомному helm-чарту. Уязвимость затрагивает все версии и была устранена в 2.3.0, 2.2.4, и 2.1.9.
Reference:
https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/
#attack #k8s #ops
Для тех, кто еще не видел, у ArgoCD вышла CVE-2022-24348 (CVSS score: 7.7), позволяющая дампить секреты из кластера благодаря кастомному helm-чарту. Уязвимость затрагивает все версии и была устранена в 2.3.0, 2.2.4, и 2.1.9.
Reference:
https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/
#attack #k8s #ops
Improving Web Vulnerability Management through Automation
Опыт Lyft по периодическому авто-сканированию внутренних веб-приложений с помощью Burp. В принципе, все отражено на схеме. В статье вы можете познакомиться с некоторыми деталями реализации. Со слов автора, благодаря данному подходу им удалось выиграть 3 дополнительных месяца инженера, но, как правильно было отмечено, так как вся информация хранится в Jira, то имеются проблемы с ограничением объема запросов и отслеживанием версий уязвимостей.
#dev #dast
Опыт Lyft по периодическому авто-сканированию внутренних веб-приложений с помощью Burp. В принципе, все отражено на схеме. В статье вы можете познакомиться с некоторыми деталями реализации. Со слов автора, благодаря данному подходу им удалось выиграть 3 дополнительных месяца инженера, но, как правильно было отмечено, так как вся информация хранится в Jira, то имеются проблемы с ограничением объема запросов и отслеживанием версий уязвимостей.
#dev #dast
How Flipkart Reacts to Security Vulnerabilities
Пятница - отличный день, чтобы вернуться к постам после продолжительного перерыва. Начнем мы с несложной темы для восприятия - с организационных процессов.
Команда Flipkart рассказывает, как устроены их AppSec-процессы по обработке уязвимостей: источники уязвимости, как они выглядят в Jira, какие есть роли в процессе по устранению уязвимостей, атрибуты, что такое "иммунизация", из чего состоит их обучение разработчиков.
https://blog.flipkart.tech/how-flipkart-reacts-to-security-vulnerabilities-17dae9b0661e
Данные проблемы можно решать не только через Jira, приводя за собой ее проблемы. Мы, например, в Альфа-Банке пошли по пути реализации собственного инструмента оркестрации AppSec (через "платформизацию"), который выполняет задачи, связанные с запуском необходимых сканеров (вроде, nuclei) и обработкой полученных результатов, решая часть упомянутых проблем.
#dev
Пятница - отличный день, чтобы вернуться к постам после продолжительного перерыва. Начнем мы с несложной темы для восприятия - с организационных процессов.
Команда Flipkart рассказывает, как устроены их AppSec-процессы по обработке уязвимостей: источники уязвимости, как они выглядят в Jira, какие есть роли в процессе по устранению уязвимостей, атрибуты, что такое "иммунизация", из чего состоит их обучение разработчиков.
https://blog.flipkart.tech/how-flipkart-reacts-to-security-vulnerabilities-17dae9b0661e
Данные проблемы можно решать не только через Jira, приводя за собой ее проблемы. Мы, например, в Альфа-Банке пошли по пути реализации собственного инструмента оркестрации AppSec (через "платформизацию"), который выполняет задачи, связанные с запуском необходимых сканеров (вроде, nuclei) и обработкой полученных результатов, решая часть упомянутых проблем.
#dev
Medium
How Flipkart Reacts to Security Vulnerabilities
Strategies and procedures at Flipkart for making software immune to recurring vulnerabilities
Code Review Hotspots with Semgrep
Автор сегодняшней статьи предлагает поделить сработки на две группы -
Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?
В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?
Здесь позволю себе высказать собственное мнение, как мы делим сработки на
#dev #sast
Автор сегодняшней статьи предлагает поделить сработки на две группы -
security и hotspots. Сработки группы security имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?
В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?
Здесь позволю себе высказать собственное мнение, как мы делим сработки на
security и hotspots в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep. #dev #sast
Securing Developer Tools: Package Managers
Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.
В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в
#dev
Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.
В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в
go.sum и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".#dev
Sonarsource
Securing Developer Tools: Package Managers
Yarn, Pip, Composer & friends: Learn about 3 types of vulnerabilities we found in popular package managers that can be used by attackers to target developers.
Уязвимость в репозитории NPM, позволяющая добавить сопровождающего без подтверждения
“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.
Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”
https://opennet.ru/57108/
#dev #news
“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.
Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”
https://opennet.ru/57108/
#dev #news
CI/CD Security - то, без чего DevSecOps не имеет смысла
13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про безопасность пайплайнов: мисконфигурации CI/CD, небезопасная среда разработки и непроработанная модель угроз для внутренних разработчиков и администраторов. Почему все эти вещи, как итог, приводят к тому, что внедрение DevSecOps перестает нести в себе ценность. Расскажу про наш опыт в Альфа-Банке и постараюсь разобраться, что надо сделать, чтобы занять золотую середину между паранойей и удобством разработки.
#talks
13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про безопасность пайплайнов: мисконфигурации CI/CD, небезопасная среда разработки и непроработанная модель угроз для внутренних разработчиков и администраторов. Почему все эти вещи, как итог, приводят к тому, что внедрение DevSecOps перестает нести в себе ценность. Расскажу про наш опыт в Альфа-Банке и постараюсь разобраться, что надо сделать, чтобы занять золотую середину между паранойей и удобством разработки.
#talks
Наиболее распространенные уязвимости в мобильных приложениях
Вы могли заметить, что я почти не пишу ничего про безопасность мобильных приложений (и вы окажетесь правы), но сегодня я хочу сделать исключение.
Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.
#dev #mobile
Вы могли заметить, что я почти не пишу ничего про безопасность мобильных приложений (и вы окажетесь правы), но сегодня я хочу сделать исключение.
Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.
#dev #mobile
CIS_SSC.pdf
642.9 KB
Security Wine (бывший - DevSecOps Wine)
CI/CD Security - то, без чего DevSecOps не имеет смысла 13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про…
CI/CD Security — то, без чего DevSecOps не имеет смысла
Спустя год после выступления вышла запись моего доклада с DevOps Conf 2022 про безопасность CI/CD. За год, конечно, тема набрала еще больше популярности, из-за чего многие упомянутые тезисы стали терять смысл освщеения, но я все же осмелюсь опубликовать.
CI/CD Security — то, без чего DevSecOps не имеет смысл
Кстати, также советую посмотреть два других достойных доклада на тему безопасности:
- SOAR в Kubernetes малой кровью
- Современная безопасность контейнерных приложений
#cicd
Спустя год после выступления вышла запись моего доклада с DevOps Conf 2022 про безопасность CI/CD. За год, конечно, тема набрала еще больше популярности, из-за чего многие упомянутые тезисы стали терять смысл освщеения, но я все же осмелюсь опубликовать.
CI/CD Security — то, без чего DevSecOps не имеет смысл
Кстати, также советую посмотреть два других достойных доклада на тему безопасности:
- SOAR в Kubernetes малой кровью
- Современная безопасность контейнерных приложений
#cicd
YouTube
CI/CD Security — то, без чего DevSecOps не имеет смысла / Денис Якимов (Альфа-Банк)
Приглашаем на DevOpsConf 2025, которая пройдет 7 и 8 апреля 2025 в Сколково в Москве.
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
Объединенная конференция DevOpsConf и TechLead Conf
13 и 14 июня 2022
Тезисы…
Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2025
---------
Объединенная конференция DevOpsConf и TechLead Conf
13 и 14 июня 2022
Тезисы…
Что не так с ASVS?
Мой небольшой пост в Linkedin про неправильное использование ASVS и его недостатки для неподготовленного читателя, а именно: перегруженность, большое число заимствований и оторванность от риск-ориентированного подхода. Последнее подразумевает то, что оценка на несоответствие ASVS по сути не означает, что ваша система небезопасна. Она означает несоответствие лучшим практикам, которые, на самом деле, не всегда применимы к вашему приложению и имеют смысл для инвестирования ресурсов. Тем не менее, все еще есть мнение, что ASVS это ready-to-use стандарт, требующий минимум кастомизации. В комментариях, кстати, контрибьютеры ASVS озвучили свои мысли по этому вопросу. Кроме того, оттуда же я узнал об очень классном портале OpenCRE, где агрегированы требования из разных стандартов.
Используете ли вы ASVS в своей организации и как?
P.S. Текст продублирован в комментариях
Мой небольшой пост в Linkedin про неправильное использование ASVS и его недостатки для неподготовленного читателя, а именно: перегруженность, большое число заимствований и оторванность от риск-ориентированного подхода. Последнее подразумевает то, что оценка на несоответствие ASVS по сути не означает, что ваша система небезопасна. Она означает несоответствие лучшим практикам, которые, на самом деле, не всегда применимы к вашему приложению и имеют смысл для инвестирования ресурсов. Тем не менее, все еще есть мнение, что ASVS это ready-to-use стандарт, требующий минимум кастомизации. В комментариях, кстати, контрибьютеры ASVS озвучили свои мысли по этому вопросу. Кроме того, оттуда же я узнал об очень классном портале OpenCRE, где агрегированы требования из разных стандартов.
Используете ли вы ASVS в своей организации и как?
P.S. Текст продублирован в комментариях
Linkedin
Sign Up | LinkedIn
500 million+ members | Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.
How Secrets Leak in CI/CD Pipelines
Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:
1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;
2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);
3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например,
Как защититься от этих сценариев?
Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :
1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)
2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.
Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .
#Dev #Ops #Secrets
Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:
1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;
2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);
3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например,
npm publish) публикует в репозитории файл конфигурации с секретами в открытом виде.Как защититься от этих сценариев?
Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :
1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)
2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.
Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .
#Dev #Ops #Secrets